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Abstract 

Writing software to control networks is impor- 
tant and difficult. It must be efficient, reliable, 
and flexible. Conduits-h is a framework fox net- 
work software that has been used to implement 
the signalling system of a multi-protocol ATM 1 
access switch. An earlier version was used to 
implement TCP/IP. It reduces the complexity 
of network software, makes it easier to extend or 
modify network protocols, and is sufficiently ef- 
ficient. Conduits-1- shows the power of a compo- 
nentized object-oriented framework and of com- 
mon object-oriented design patterns. 

1 Introduction 

A protocol stack is usually implemented with a lay- 
ered software architecture. For example, TCP sits 
on top of IP, which sits on top of the Ethernet driver 
(See figure 1). Each layer communicates with the 
layers above it and below it. Requests move up 
and down the stack from users to the network and 
hark to users again. It is not hard to build individ- 

1 Asynchronous Transfer Mode 



ual layers so that one can be replaced by another, 
such as replacing IP with SLIP 2 . However, a layered 
architecture does not adtlress reusability across lay- 
ers, Each layer requires a new implementation even 
though the different layers have much in common. 
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Figure 1: A TCP/IP Stack. 

A key problem in designing reusable comxnniii ca- 
tion protocol software is how to factor out the com- 
mon RtnictiiT* and behavior from the protocol spe- 
cific parts. Solving this problem results in software 
components that can be reused with no source-code 
modification within a variety of different protocol 
implementations. Our paper shows how to achieve 
this by applying a number of previously described 
object-oriented design patterns. Two additional 
benefits are: 
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■ The protocol specific software parts become 
simpler and easier to maintain and evolve 6ince 
the framework provides the infrastructure op- 
erations. 



3 Serial Line Internet Protocol 
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■ The result is a framework for network proto- 
col software, in other words, a generalized soft- 
ware architecture for communication protocols. 
Documenting this framework helps communi- 
cate the underlying model and how it works. 

Conduits-i- is an example of a black-box framework, 
i.e. a framework in which components are reused 
mostly by composing instances (Johnson and Foote, 
1988), In contrast, a white-box framework is one in 
which components are reused mostly by inheritance. 
White- box frameworks get their name from the fact 
that their users tend to have to know more about 
the implementation of the components they reuse. 

Blcick box framcworka arc usually oasler to use than 
white-box frameworks, but are always harder to 
design. Most black-box frameworks started off as 
whito-box frameworks and then, gradually evolved 
to become more compositional. Conduits-f was de- 
signed this way, too. The paper describes how Con- 
diuts-f evolved from a white-box framework and so 
is a case study in how to design frameworks. 

We describe the evolution of Conduits-f in terms of 
a sequence of design patterns. Design patterns are 
descriptions of communicating objects and classes 
that are customized to solve a general design prob- 
lem iu a particular context. The dt^igii palterus 
we use have all been described elsewhere (Gamma 
et aL, 1995), so we do not describe them in de- 
tail here. However, we describe the problem they 
solve and the design that results when they axe ap- 
plied. We have found patterns to be a usefuJ way 
to describe the design of a framework (Beck and 
Johnson, 1994). 

The graphic notation that we use to depict 
our architecture throughout this paper is similar 
to Booch's object-diagrams(Booch. 1994). This 
objecl-sctnario notation was invented by GLUE 
Software Engineering primarily for teaching object- 
oriented software engineering (Huni and Metz, 
1992) using C++. While developing this framework, 
it was extensively ased to communicate and docu- 
ment design-situations and has shown a lot of ex- 
pressive power, 

Conduits+ is being used in a commercial product. 
It shows that an evolutionary development of a 



framework is commercially viable, and that design 
patterns axe useful in commercial projects. 

2 Basic framework architecture 

The framework is made up of two sorts of objects. 
conduits and information chunks. A conduit is a 
software component with two distinct sides, sideA 
and sideB. A conduit may be connected on each of 
its sides to other conduits, which are its neighbor 
conduits. A conduit accepts chunks of information 
from a neighbor conduit on one side and delivers 
them to a conduit on the opposite side. Conduits 
axe bidirectional, so both its neighbors can send it 
information. 
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Figure 2; Four kinde of conduits. 

There are four kinds of conduits as in figure 2, all 
of which, have one neighbor on sideA. A Mux can 
have many neighbors on sideB r an Adapter has no 
neighbor conduit on sideB, and a Protocol and Con- 
duitFactory have exactly one. 

We will use the vague term information chunk for 
everything that flows through conduits. We will be 
more specific in Section 3 where we refine the basic 
framework architecture and make it more reusable. 

Each layer of a protocol 6tack is implemented by 
one or more conduits. Thus, a TCP/IP stack would 
contain conduits for TCP and for IP, while an ATM 
signalling stack would contain conduits for the sig- 
nalling ATM adaption layer (SAAL), the actual 
layer 3 signalling and the call control layer which 
is responsible for call routing. The information 
chunks in a TCP/IP stack include Ethernet, IP. and 
TCP packets. In addition, some of the information 
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chunks represent operations like opening or closing 
a channel. Since an ATM switch transfers all data 
in hardware, all the information chunks in an ATM 
signalling stack represent operations. 

Originally we only considered strictly vertically 
stacked layers of communication, protocols a-ud so 
called the sides of a conduit upper and lower. But 
conduits can also interconnect two stacks such that 
information chunics that travel upwards in one of 
them are moved to the top of a second stack to flow 
down towards the network. Such an inter- working 3 
conduit is horizontal, proving that upper and lower 
sides do not always make 6ense, Also, some con- 
duits may have an asymmetric structure or behav- 
ior. Our new terminology lets us reuse a given con- 
duit upside-down without getting confused. 



2.1 The Mux 

A mux is a conduit that connects one sideA conduit 
to any number of sideB conduits. A mux multi- 
plexes information chunks arriving on sideB to the 
single neighbor conduit connected on its sideA. In- 
formation chunks from sideA are demultiplexed to 
one of the neighbor conduits connected on sideB. 
The sideB instance variable of the mux in figure 2 
denotes a multi-valued variable which might be re- 
alized trough an appropriate collection class like a 
List or a Map. 

Each layer of a protocol stack can contain a mux. 
For example, in a TCP/IP stack, the Ethernet layer 
contains a, mux to connect to low-lcvcl protocols liko 
ARP and IP, the IP layer contains a mux to connect 
IP to UDP and TCP, and the TCP layer contains a 
mux to connect it to clients like ftp, telnet, or http. 

A mux for a layer like Ethernet does not need to 
add new sideB conduits dynamically, because the 
Jow level protocols that use the Ethernet are usu- 
ally specified when the operating systems kernel is 
built. But a mux for the TCP layer must be able to 
add new connections dynamically. Thus, it is im- 
portant for it to be easy to install and disconnect 
sideB conduits. 



A mux must be able to extract a dispatch address 4 
from an information chunk arriving from sideA and 
demultiplex the information chunk to the neighbor 
conduits on sideB- For example, a mux in an IP 
layer must extract a service identifier from the IP 
message to tell whether to dispatch it to TCP or 
UDP, and an ATM signalling system must dispatch 
the information chunks to conduits representing in- 
dividual calls based on a call-reference. In the op- 
posite direction, a mux must provide an identifier 
that represents the sender sideB conduit so it can 
label the information chunk when it multiplexes it. 

2.2 The Protocol 

A communication protocol can be described by a 
finite state machine (FSM) and is implemented by a 
protocol conduit, which, is where information chunks 
are produced, consumed, and tested. The protocol 
remembers the current state of the communication- 
It also provides commonly required facilities such as 
counters, timers and storage for information chunks 
to be temporarily retained. A protocol has exactly 
one neighbor conduit connected on both of its sides. 
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Figure 3: Three Protocols on a Mux. 

In general, a single layer in a protocol stack will 
be implemented by several conduits, each special- 
ized for a single role. For example, a TCP layer 
really consists of a protocol conduit to implement 
the protocol and a mux to dispatch packets to TCP 
connections. Thu6, a layer in the protocol stack is 
a string of conduits. 



3 Mapping one type of communication protocol to a similar 



4 The terms address, identifier, index, dispatch-key and 
session-key all mean the same thing in different situations. 
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2.3 The ConduitFactory 

One important design problem is how to add new 
sideB conduits to a mux. Another design problem 
is what a mux should do with an information chunk 
from sideA that addresses a non-existing conduit on 
sideB. We solve both these problems by giving each 
mux a default conduit that is a neighbor conduit 
connected on sideB of the mux on the dedicated 
bO channel. Each mux has exactly one default con- 
duit, and zero or more other sideB conduits. In 
the IP layer, information chunks sent to the default 
conduit have illegal service identifiers, so we would 
use a default conduit that logs errors and responds 
to them. In ATM signalling systems, information 
chunks that are delivered to the default conduit in- 
dicate that a new call (or more commonly a new 
session) needs to be established, so the default con- 
duit should install a new sideB conduit. 
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Figure 4; A Mux with a ConduitFactory as its 
default conduit. 

Our architecture (See figure 4) can create and in- 
stall new sideB conduits for a mux using a conduit 
factory as the default conduit to a mux. When- 
ever a new session has to be set up, the information 
chunk received from sideA of the mux will be deliv- 
ered to its default conduit (on channel bO). It thus 
aiiivea at the conduit factory* which then installs 
a new instance of the required session protocol on 
sideB of the mux. That same information chunk 
that the mux was prcvioucly unable to handle will 
now revisit the mux and can correctly be demulti- 
plexed to the just installed protocol conduit. The 
next tinic on information chunk with such a session 
key arrives at the mux, it will be directly handed 
off to that new session protocol. 



The dashed line originating at a Conduit Factory in 
figure 4 denotes a global reference 5 to the class of 
the object. The operation createQ is applied, ac- 
cording to this reference, on class Protocol to pro- 
duce the instance aProtocol. 

2.4 The Adapter 

At> adapter is a kind of conduit that has no neigh- 
bor conduit on its sideB. Thus, only its sideA is 
connected to another conduit. The adapter conduit 
is used to interface the framework to some other 
software or hardware. Its sideB implementation is 
usually specific to a particular software or hardware 
environment. For example, an Ethernet conduit is 
an adapter for hardware, while a http-client cond\ut 
is an adapter for application programs wanting to 
be an http-client. 

The adapter often converts information chunks to 
and from an external stream-oriented format. It 
might simply interface to some li brary written in C 
by registering a call-back function with the library 
and offering a sideB function that accepts a stream 
to road from. 

2.5 Summary of Architecture Model 

Conduits-}- divides a network protocol implementa- 
tion into the parts that process information, which 
are the conduits, and the parts that represent the 
information being processed, which are the infor- 
mation chunks. Conduits have two basic interfaces, 
one for connecting conduits to neighbors and ac- 
cessing those neighbors, and one for handling infor- 
mation chunks. AH conduits share these interfaces. 

Although one might argue that separating function 
from data is not very object-oriented. Conduit 5+ 
uses object-oriented techniques heavily, First, it 
uses inheritance to organize a hierarchy of conduits. 
Class Conduit has four subclasses, Mux, Protocol, 
Adapter, and ConduitFactory, and each of them 
may also be subclassed. Second, it uses polymor- 
phism to make it possible to connect any kind of 
conduit to any other. As long as each conduit only 

5 We use dashed lines for global relations as well as to 
depict classes or modules 
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assumes that its neighbors support the Conduit in- 
terface, any kind of conduit can connect to any 
other. 
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Figure 6: A typical conduit graph. 

Since a conduit can be connected to any other kind 
of conduit ? wc can build arbitrary graphs out of 
these few simple components. Information chunks 
can then flow through the conduit graph to cause 
state- changes at protocol conduits. Figure 5 shows 
an example of a conduit graph as used to imple- 
ment the layer 3 signalling protocol 6 in ATM (En- 
gel, 1G95). 



3 Design Patterns improve the 
architecture 

The architecture described in the previous section 
is not as reusable and extendible as it should be. In 
particular, a naive implementation of this architec- 
ture might require subclassing Protocol to define a. 



6 Q.2931 as specified by ITU 



new state machine, subclassing Mux to specify how 
addresses are extracted from information chunks, or 
subclassing ConduitFactories to describe the kind 
of conduit that should be added as a sideB con- 
duit of a mux. These problems can all be solved 
using existing design patterns, resulting in a black- 
box framework that is elegant, highly reusable and 
easily extendible. We've already used some of these 
patterns, since Mux is an example of the Composite 
pattern and Adapter is an example of the Adapter 
pattern. But the next patterns that we use are 
more obviously design patterns, since they are being 
used only to provide a more flexible solution, not to 
model the problem domain better. 

3,1 Strategy Pattern 

We want to be able to reuse the same Mux class 
at different places in the conduit lattice. Therefore, 
we need to configure a mux with a dispatch criteria. 
We call these components Accessors, since they ac- 
cess the relevant dispatch key within an information 
chunk. Moreover, a new conduit being installed on 
sideB of a mux sometimes needs a new session key 
according to some policy. This session key genera- 
tor can also be hidden within the Accessor. 

Each mux lias an Accessor, which has two respon- 
sibilities. One is to compute the index of the sideB 
conduit to which the current Inform ationChunk 
should be dispatched. The other is to compute an 
index for a new sideB conduit. Thus, a mux will 
handle an information chunk that arrives on sideA 
by using itc Accessor to got an index, and then Bond- 
ing the information chunk out on the sideB conduit 
with that index. 

In figure 6, a reference to alnforniationChunk is de- 
livered as a method parameter from aConduit to 
aMux. The same reference is passed by method get- 
DispKey to aTCPAccessor. To avoid cluttering this 
diagram with too many lines, we use the short-name 
ic of alnformationChunk to indicate this. When 
aTCPAccessor gets a reference to the information 
chunk, it invokes the provideTCPconnID method 
on it. 

Separating an algorithm from the object that uses 
the algorithm is called the Strategy pattern. The 
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Figure 6: The strategy pattern object -scenario. 

intent of the Strategy pattern is to let the algo- 
rithm, or strategy t vary independently from clients 
that use it. The mux is the context of the strategy, 
and the Accessor plays the role of the strategy. Ac- 
cessors abstract out the difference between different 
mux objects on different layers in a protocol stack, 
so that the mux no loivgtir has lo be subclassed. 
Instead, a mux is given a reference to its Accessor 
when it is created. 

The TCPAccessor knows how to extract a field from 
the TCP message that is its information chunk. 
In an ATM signalling system, the CallRjef Accessor 
fetches the call number, while an EndPointRefer- 
enceAccessor gets the various parties in a point-to- 
multipoint situation. 

3.2 State, Singleton and Command 
Patterns in concert 

A communication protocol is usually realized by 
some (extended) finite state machine (FSM). It 
changes state when it receives Inform ationChunks 
or when a timer expires. Protocols are implemented 
using the State pattern, which means that each 
state of the Protocol is represented by a separate 
object. Protocols delegate their behavior to their 
state object, thus letting the protocol change its be- 
havior when its state changes. A protocol changes 
its state by replacing its old state-object with a new 
one. 

The State pattern in the Design Pattern book 
(Gamma et a]., 1995) gives a broad interface to both 
the context (Protocol) and the state-object (State). 
This interface has an operation for each possible 
event. Thus, a TCP protocol conduit would have 



operations like Open Connection, (JloseConnection, 
and Send, and it would delegate all these operations 
to its state object. However, different protocols re- 
spond to different sets of events, so this would give 
different protocols different interfaces, limiting the 
reusability of Protocol. 

Our version of the State pattern makes the protocol 
conduit more reusable. The protocol offers just one 
method, a method to accept information chunks. 
The information chunk interacts with the state ob- 
ject, usually invoking protocol- specific operations 
on it. Thus. State offers a relatively broad interface 
to the information chunks, but Protocol has a nar- 
row interface. When a protocol is given an informa- 
tion chunk, it performs the apply (aState,aProto col) 
operation on the information chunk, giving it both 
its state object and the protocol as arguments. The 
information chunk implements the apply operation 
by invoking an operation on the state object. 
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Figure 7: State, Singleton and Command pattern 
interactions. 

Raw information chunks are often just arrays of 
bytes, so it is not appropriate to define operations 
like apply () for them. Instead, we introduce a 
new class Messenger that contains the information 
chunk and defines the Apply () operation. A Mes- 
senger represents an event or an operation that is 
going to be invoked on the FSM of Protocols that 
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it encounters as it is passed through the graph of 
conduits. Thus, it i6 an example of the Command 
pattern. 

The purpose of the Command pattern is to encap- 
sulate a request as a first-class object so it can be 
manipulated in some way. Using the Command 
pattern lets any conduit handle any Messenger by 
passing it along to a neighbor conduit. Protocol 
conduits handle Messengers by applying them on 
their current state object. This can not be done di- 
rectly in a language like C++ where requests invoke 
methods and there is no first- class representation of 
requests to be passed around. 

A communication system will probably have a large 
number of protocol objects in use at the same time, 
so the state objects should be sharable. This implies 
that they are immutable. This means that we have 
to stOTe any mutable variables like timcrc, count ere, 
etc. in the protocol object but manipulate them 
from the state object. 

Each protocol requires a new State class hierarchy 
with a new derived class for each state in the finite 
state machine. Since there will always be at most 
one instance of such a state class, it maices sense to 
use the Singleton pattern for all state classes. Thus, 
there will be exactly one instance of each state class, 
and they will not have to be dynamically created or 
destroyed. 

Figure 7 shows how a messenger interacts with a 
protocol and its state object. In this figure, the 
messenger represents the release operation. It ar- 
rives from sideB, is applied on the current state cs, 
sets timer number 7 to 200 msec, changes the state 
of the protocol from cs to rs, and then proceeds to 
the neighbor on sideA. Note that the definition of 
how the protocol responds to the release command 
in state cs is implemented only by its class Connect- 
edState. In general, all protocol specific code is in 
the State classes, with each Messenger just invoking 
a single operation on the state. 

The Messenger and State classes axe protocol spe- 
cific. The state classes are usually not reusable from 
one communication application to another, though 
Borne of the Messenger classes might. Class State 
is tightly coupled to all of the Messenger classes, 
since it must implement all the operations that any 



oi them perform on it. 

Notice that messengers and states use double- 
dispatching (Ingalls, 1986). The first dispatch is 
to the messenger, and it performs the second dis- 
patch on the state. Thus, the eventual function on 
the state depends on both the class of the messen- 
ger and the class of the state. This is exactly the 
situation that we expect for a transition in a FSM. 

3.3 Visitor Pattern 

A typical messenger is routed through a mux un- 
til it gets to a protocol, where it interacts with a 
6tate. However, some operations must traverse the 
conduit graph differently, especially when conduits 
are being added or removed from a mux. One al- 
ternative is to add new lands of accept operations 
to Conduit, but Lh<tt would defeat the purpose of 
the Command pattern. Another alternative is to 
make the messenger responsible for traversing the 
conduit graph, but that would couple Messenger to 
Conduit. Since the Messenger class hierarchy is al- 
ready strongly coupled to the State classes (which 
are protocol specific), it ia better to capture the non- 
specific and thus reusable algorithms for conduit- 
traversal in a separate class. 
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Figure 8; Framework class collaboration graph. 
The solution to this problem is the Visitor pattern. 
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The intent of the Visitor pattern is to represent an 
operation to be performed on the elements of an 
object structure, which in this case is the conduit 
graph- Visitor lets you define a new operation on 
conduits without changing the classes of the con- 
duits. It does this by making these operations on 
conduits be subclasses of the abstract class Visitor. 
Conduits will only have to deal with Visitors, so 
they will not depend on the Messenger hierarchy. 
Visitor has several subclasses. One of them is Msg- 
Transporter, which carries a Messenger around the 
conduit graph. Same Visitor subclasses help change 
the conduit graph. Installer is a land of visitor that 
usually originates from a conduit factory. It installs 
» ronrliiit object on the first Mux sideB it encoun- 
ters. Figure 8 presents the framework's most im- 
portant classes in the form of a class collaboration 
graph (Wirfs-Brock et ah, 1990). 
A visitor arrives at a conduit when the accept(V) 
operation is invoked by a previous conduit. The 
conduit then performs an operation on the visitor 
that indicates the class of the conduit. If it is a 
mux then it performs the atMux(M,C) operation, if 
it is a protocol then it performs the atProtocol(P,C) 
operation, and so on. 

Thus, the visitor gets to know the conduit f s subclass 
through the method that is invoked on It. Since 
the first argument is of type pointer to the subclass 
the visitor is able to invoke specific (subclass only) 
methods on this argument. The method lnslallOii- 
SideB(...) in figure 8 is such a method that is only 
available in the subclass Mux and is invoked from 
within the method InsiaHer::atMux(M,C). 

The visitor therefore decides on the appropriate ac- 
tion based on the conduit type, its own type and 
additional information it carries along. 

When a MsgTranspoxter encounters a mux. it must 
traverse it, so it rails toA(V) or toB(V) depending 
on its direction. But when encountering a protocol 
as in figure 9, it should apply its messenger on the 
protocols current state object. Other visitors may 
behave differently when encountering each kind of 
conduit. 

While innssengers axe commands for states, vicitorc 
can be thought of as commands for conduits. But 
while messengers will always just execute a method 
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Figure 9: A MsgTransporter encounters a protocol 
on sideA. 

of a given name on their target state object, visitors 
may do different thinga based on the kind of conduit 
they encounter. The effect of a messenger on a state 
(a transition) is detennined by the state, but the ef- 
fect of a visitor on a condtdt can "be decided by the 
visitor. This is a good trade-off because new states 
are more likely than new messengers, and new visi- 
tors are more likely than new conduits. The visitor 
pattern is like a more powerful command pattern 
because the visitor may initiate whatever is appro- 
priate for the kind of the conduit it encounters. 

Visitors must traverse conduits in both directions. 
One way to accomplish this is to give conduits two 
kinds of accept operations, acceptlrornAQ and ac- 
ceptFromB(), Each kind would pass the visitor 
along to the other side. But this complicates how 
conduit graphs may be assembled because the pre- 
vious conduit must know whether it is connected to 
a sideA or a sideB of its neighbor conduit. 

Instead, conduits have only one kind of accept op- 
eration, and visitors are responsible for traversing 
conduits. One approach would be to have visitor 
subclasses VisitorFromAtoB and VisitorPromBtoA. 
But this would lead to too many subclasses and 
could not deal with two interconnected kIHp.A 'r. The 
real notion of direction during this traversal 5b just 
going to the opposite side from where the visitor ar- 
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rived, A visitor always knows its previous sender 
conduit, so it can figure out whether or not it ar- 
rived on the conduit's sideA and thus determine 
the opposite side. When conduits invoke an atXXX 
method upon a visitor, they always pass their sideA 
neighbor conduit as the last parameter. 
The complexity added by the Visitor pattern is 
compensated by the fact that a VisitoT can travel 
over a whole string of con dixit s Kf»foTe encountering 
its destination kind of conduit. In particular, it is 
easy to implement switching and routing function- 
ality; as we will see in spr.tinn 4. 

3.4 Prototype Pattern 

A conduit factory must be parameterized by the 
kind of conduits that it creates. An easy solution 
is for each conduit factory to define a function that 
creates its conduits (the Factory Method pattern), 
but this would require a new subclass of Conduit- 
Factory for each new kind of conduit factory. A 
better solution is for each conduit factory to have 
a prototypical conduit that it copies when it needs 
to create a new one. This is an example of the 
Prototype pattern, which is specifying the kinds of 
object to create by using a prototypical instance. 
Using the Prototype pattern requires that conduits 
be able to copy themselves. It permits conduit fac- 
tories to be specified by parameterizing an instance 
of ConduitFactory with a conduit graph that is an 
example of the conduits to be installed when a Mux 
needs a new sideB. 



Call routing in 
signalling system 



an ATM 



ATM is loo fast to rely on software to switch data. 
The result is that ATM separates signalling infor- 
mation from data traffic, with the software handling 
the signalling infomiatioii and the hardware c witch 
ing the data. The ATM software steers the data by 
controlling the switch. It keeps track of the state of 
the calla and changes the o witch when calls change 
state. Even though data is not flowing through the 
conduit graph, the conduit graph stores the state 



of the calls, so there will be a path of conduits for 
each call. 

One of the most difficult problems in applying Con- 
duits-*- to ATM software is handling call routing. 
An ATM switch typically supports many trunks, 
and a call can originate in any trunk and end in 
any trunk. The trunks are connected by a cross- 
bar switch, but a Mux is a 1-to-N switch, not a 
N-to-N switch. However, Conduits* can represent 
this situation, too. 

The object scenario in figure 10 shows a simplified 7 
version of the initial conduit gr*ph for call handling 
and routing in an ATM signalling system. Only two 
trunks are shown, but there can be any number of 
them. Thp. rmrx at the top is used together with 
a specialized visitor to establish new connections 
between trunks. Note that it is connected to the 
conduit factories of each trunk's mux. 
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Figure 10: Initial conduit graph for 2 trunks with 
no active calls. 

Initially, when no calls are in progress or estab- 
lished, every trunk in the system has one adapter, 
one link protocol (ipl, lp2), a mux and a conduit 
factory. Each new call will create a string of new 
conduits. 

Suppose a now cajl is initiated on trunkl. The 
adapter creates a MsgTrausporter with a SetupMes- 
senger, which will arrive at the conduit factory cfl 

r Ascoro's multi-protocol ATM access switch is able to han- 
dle paint-to-multipoint connections. This basically involves 
one more demultiplexing stage. 
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to create and install a new protocol spl (for layer 3 
signalling) followed by a new protocol cpl (for call- 
control). These two conduits are both instances of 
our single Protocol class. The protocol-specific be- 
havior is caused by configuring the new protocols 
with suitable state objects. The conduit factory 
installs that string of conduits using two Installer 
objects (not shown here), each of which installs one 
side of the conduit string. SideA of the protocol 
spl is interconnected with sideB of the lower Mux 
on trunk 1 while sideB of the cpl protocol is con- 
nected to sideA of the top Mux tin. This interme- 
diate result is visualized by the object- scenario of 
figure 11. 




irunkl = D/iff 



irunk2 = dot 



Figure 11: Routing a call with a Cross Connecter 
from one trunk to another. 

The MsgTransporter with Us SetupMessenger will 
now visit protocol spl and then protocol cpl. Here, 
the call has to be routed from its origin trunk to 
some destination trunk. Protocol cpl is responsi- 
ble to initiate this. It sets up a path to the des- 
tination trunk by creating a special visitor called 
a Cross Connecter, which remembers the cpl proto- 
col that created it and also a destination trunk-ID. 
The CrossConnecter cc is sent by the cpl protocol 
on ilu tsideD, laijaiedia.tcly visiting the top mux tm, 
at which point it is dispatched, based on its dest- 
TrunkID, to the conduit factory cf2 of the correct 



destination trunk. 

At this point, the CrossConnecter will ask the desti- 
Tiafcirm conduit factory to provide a new destination 
conduit string through the same mechanism as the 
origin one did. This leads to the creation of a new 
signalling protocol sp2 and anew call-control proto- 
col cp2 as shown by the object- scenario of -figure 12. 
The CrossConnecter will finally have to establish 
the interconnection of the two protocol conduits cpl 
and cp2. 

The SetupMessenger, which has been remembered 
by the origin cpl protocol, can now continue to bo 
carried by a MsgTransporter from sideB of this pro- 
tocol to sideB of the destination cp2 protocol and 
eventually down the destination protocol stack to 
the adapfcer of the destination trunk. 
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Figure 12: The final interconnected conduit path 
for the new call. 

Other operations in an ATM signalling system are 
much more straightforward. For example, when a 
call is released, the entire conduit string between 
the origin mux and tho destination mux has to be 
destroyed. A release request may be initiated from 
both parties connected by the call. Every proto- 
col conduit will usually handle this event grarnfnlly 
within its FSM. Before a conduit is destroyed, it 
has to inform all neighbor conduits on its sideA 
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and sideB through an object of class Disconnecter, 
which is some kind of Visitor. The Disconnecter 
ob ject must remove the reference from the neigh- 
bor conduit to the dying conduit, 

5 Framework evolution and 
related work 

The framework started out as a white-box frame- 
work that relied heavily on inherit ance» and grad- 
ually became more black- box.. CuuduiLb was origi- 
nally designed by Jonathan Zweig for his MS the- 
sis (Zweig and Johnson, 1990) and used to imple- 
ment TCP /IP. Bui this version did not separate 
Mux from Protocol, did not use the Visitor pat- 
tern, and did not have Conduit Factory. Thus, each 
kind of conduit required a separate subclass, and 
adding new protocols required much more develop- 
ment and testing. 

Another excellent source of inspiration, although 
just using object-based technology, was some follow- 
on work of the x-kernel group on a language for 
protocol implementations called Morpheus (Abbott 
and Peterson, 1993). The authors claim that; Mor- 
pheus 1 benefits could not be duplicated by adding pre- 
defined classes to a general object-oriented language 
like C++ since it would lack the knowledge of com- 
mon patterns of protocol operation invocation that 
Morpheus exploits to optimize. 

While our framework is unlikely to achieve the same 
execution efficiency as a special -purpose program* 
ming language, it offers similar, but more easily ex- 
tensible ? compositional facilities. An important ad- 
vantage is that it can be implemented with a stan- 
dard C++ compiler. 

In September 1993. a team at As com Tech started 
the design of ATM signalling sofLware. using Con- 
duits as a starting point. The team was small and 
only one member had extensive experience with 
object-oriented technology and C++. By January 
1994, the framework had been used to implement 
the layer 3 ATM signalling protocol (Q.2931). Since 
then, Lhe frame work has undergone a number of ma- 
jor revisions and extensions, and is being used to 
implement multiple layers of the signalling system 



within a flexible multi- protocol ATM access switch 
being marketed today. 

The first version of the ITT J Q.2931 signalling pro- 
tocol implementation was based on an unapproved 
specification. The approved version introduced 
mainly one new feature. The feature required the 
link protocol (lpl in figure 12) to be able to issue a 
Synchronization MftKsengeT to all signalling protocol 
instances (like spl in figure 12). 

At first glance this requires just a minor extension. 
However, with a classical approach, it is not that 
easy to broadcast such control information to all 
currently running protocol instances. Our frame- 
work solves the problem by adding a BroadcastVis- 
itor, A Broadcast Visitor has a special behavior 
when it encounters a Mux. on sideA. Ins Lead of de- 
multiplexing to some sideB conduit, it broadcasts 
to all conduitB connected on sideB of the Mux. The 
effort to design, implement and test this extended 
feature was less than a week's work. 

There are certainly more refinements to come. The 
currently hardest question is how factor the slight 
differences between network- and user- side proto- 
cols y between upwards compatible revisions of the 
same protocols, between protocol variations of dif- 
ferent standard-bodies (ITU, ATM Forum) and be- 
tween incremental feature sets to be added on de- 
mand to a protocol. We are currently investigating 
solutions that permit even higher levels of reuse in 
the area of States and Messengers, 

Moat new protocols require creating only new state 
classes. Conduits, Visitors, and even Messengers 
can usually be reused. But state classes have very 
regular and predictable interfaces, and it eoems 
likely that they could be constructed automati- 
cally from higher-level specifications (ITU-T, 1993). 
Prototype based Conduit Factories are specified by 
graphs of conduits, and the initial protocol stack is 
a graph of conduits. It seems likely that both can 

bo opacified graphically. Thus, it seems possible to 

create a protocol builder in the same sense as there 
are many object-oriented interface builders. 
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6 Conclusion 

Software for network protocols that me^ts inter- 
national specs is often quite complex and hard to 
build. We have shown how to segregate a reusable 
infrastructure of black- box components into a co- 
hesive framework and encapsulate the protocol spe- 
cific parts into a few extra classes that are relatively 
easy to build and maintain. 

Our design developed in steps. Particular reuse 
problems led to design patterns that solved them. 
The result was that most of the components of 
the framework became protocol independent. This 
means that someone using the framework can con- 
centrate on just that part of the framework that 
needs to be customized, and can pay less attention 
to the rest. This leads to a framework that is much 
easier to learn and use. 

This paper has concentrated on an architectural 
model and how design-patterns improve its flexi- 
bility and reuse-potential. This is only one of the 
issues that must be faced when designing a frame- 
work. Questions like inemoiy management policies, 
scheduling of potential parallel activities, execution 
efficiency and testing facilities are also important 
but our solutions to these problems are not ex- 
plained here. 

Even though the design will continue to improve, 
it has already prvven ita "worth. It hae allowed 
a small group to develop complex software in a 
short amount of time, and has allowed us to rapidly 
change vur software to track the proposed standards 
as they are revised. 

We would like to thank Toni Bieri. Walter Bischof- 
berger, Erich Gamma, Brian Fbote, Philippe Oech- 
slin and Lennart Ohlsson for their constructive com- 
ments on earlier drafts of this paper. 
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